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Subject: PDP-10 Product Options 



I .0 



ntroduction 



During the repianning stages of the Jupiter II project, questions 
have been raised concerning the decision to build a CPU whose 
nominal performance is four times a KLIO. Why, it has been asked, 
should we not build something whose performance is less than kx a 
KLIO but which we could ship sooner? This memo analyzes the 
possible alternatives and presents arguments that support our 
deci si on. 



2.0 What are the options? 

In looking at the available options, it seems clear that the 
number is limited. We must either do some sort of KLIO conversion 
or build a variant of the Jupiter architectural design. To do 
anything else would require a major development effort with a 
corresponding increase in schedule. 

We have invested over three years effort working the bugs out of 
the architecture with the result being the Jupiter architectural 
design. This design includes the following significant 
enhancements of previous designs: 

o Full virtual address space implementation. The Jupiter design 
includes support for the full 30-bit virtual address space as 
defined by the architecture. The KLIO implements a 23-bit 
subset of the virtual address space. 



o Correct implementation of the extended addressing 
architecture. The Jupiter design correctly implements the 
f ul 1 archi tecture. 
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o Enhancements to the hardware monitor interface. The Jupiter 
design includes enhancements to supply more information to the 
monitor on interrupts, page faults, and MUUOs. This 
information reduces the number of times that the monitor has 
to "guess" what happened and increases the efficiency and 
performance of the interface. 

o Enhancements to improve timesharing efficiency. The Jupiter 
design includes enhancements to decrease the cost of context 
switching and other mul ti-programmi ng effects. 

o Increased functionality. The Jupiter design includes 
increased functionality in areas which are weak in previous 
implementations of the architecture (e.g., address break). 



o Designed-in interface to corporate buses. The Jupiter design 
includes integral interfaces to the CI and Nl buses. These 
interfaces were part of the original architectural design and 
do not exhibit the problems of "added on later" interfaces. 

The Jupiter architectural design takes advantage of an eight year 
learning curve with the KLIO and KSIO designs. 



3.0 A possible KLIO conversion 

When considering producing a PDP-10 that is a conversion of the 
existing KLIO design, one must consider several things. 

The existing PDP-10 design team has little experience with the 
KLIO design. Most of the original KLIO designers have moved to 
other groups and would not be available for such a conversion. 
The ramp-up time to learn the KLIO design in the detail necessary 
to do a low-risk conversion could be quite high. 

The KLIO design exhibits a large number of bugs, mostly relating 
to extended addressing and PXCT. At present, these bugs are being 
circumvented in software, but it's only a matter of time before we 
find a bug that can't be fixed in this manner. If the conversion 
is to be a design that will last, these bugs must be fixed as part 
of the conversion. This makes the process less of a conversion 
and more of a design effort. 

A KLIO conversion into gate arrays is a non-trivial task. Because 
gate arrays cannot be ECOed, extensive design verification 
techniques must be used at the expense of schedule. Our estimates 
of the cost of doing the Jupiter design in gate arrays indicate 
that there is an added cost of 9 months because of the 
verification process that is necessary. An equivalent schedule 
penalty is probably applicable to a KLIO conversion to gate 
arrays. 

Due to bus width limits, the KLIO physical memory addressing 
capability is limited to k Mwords. Analysis indicates that this 
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is probably insufficient to support a machine whose speed if much 
greater than a KLIO. Any KL10 conversion would have to include an 
expansion of the physical address space. 

Any KLIO conversion would have to include the design of more 
optimal I/O interfaces to the CI and Nl buses. While there exist 
CI and Nl interfaces today, the requirement that they obey the 
RH20/DTE20 protocol inhibits the efficiency of the interfaces. 
They are in essence, bolted-on interfaces that are limited by the 
design of previous interfaces. 

Finally, converting the KLIO to lOKH or MCA technology appears to 
be limited to a performance increase of 1. 5-2.0. 



U.O A Jupiter, but at what speed? 

Even if the Jupiter architectural design is used to build a 
PDP-10, there is the question of the optimal goal for the machine 
performance. Selecting such a goal is a function not only of the 
technical difficulties in achieving the goal, but also 
time-to-market questions. The optimal product is obviously one 
which has an infinite KC/KL ratio and which would be available 
next week. In the absence of such a product, what is the optimal 
tradeoff between performance and time-tc-market? 

First, let's consider the technical difficulties involved in 
implementing a Jupiter design at various KC/KL ratios. Based on 
previous performance analysis, we believe that a machine whose 
nominal performance i s 2 to 3 times a KLIO is relatively easy to 
do. A machine whose performance is kx a KLIO is within reach, but 
some careful design must be done to use the available gate 
resources in an optimal way. Finally, a machine whose nominal (as 
opposed to peak) performance is 5x a KLIO appears to be quite 
difficult to do. 

Therefore, from a technical viewpoint, the choice seems to be 
between a machine in the 2-3x a KLIO and one which is 4x a KLIO. 
Let us consider possible schedules for both machines. 

The primary difference in the design of these two machines is the 
requirement that additional design work must be done during the 
architectural and register transfer design stages of the kx 
machine. Some additional simulation may also be necessary to to 
confirm that the performance goals are met. Our estimates are 
that this additional work amounts to no more than 3 to 6 months in 
additional schedule. 

It is also worthwhile to compare the schedule for a possible KLIO 
conversion to that for a Jupiter design that is hx a KLIO. 
Because any KLIO conversion must include design time to correct 
the existing KLIO bugs, the process is not a simple conversion. 
An MCAed KLIO also involves increased risk and schedule because of 
the additional simulation time to make sure that the design is 
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correct. Our initial comparisons of these two alternatives 
indicates that a Ax KLIO Jupiter design would require no more than 
6 to 9 months additional schedule beyond even a simple KLIO 
conversion. 



5.0 Conclusions 

The viable options for building a PDP-10 seem to be limited to a 
KLIO conversion and a variant of the Jupiter architectural design. 
The Jupiter architectural design takes advantage of the eight year 
learning curve with the KLIO and solves many of the existing KLIO 
architectural problems. 

Selecting the performance goal for a Jupiter architectural design 
involves tradeoffs with time-to-marl<et. A machine whose nominal 
performance is kx a KLIO seems to be a nearly optimal choice 
between performance and time-to-marl<et considerations. In 
addition, such a machine does not have a schedule which is 
significantly longer than that for a KLIO conversion. 

Continuing with a PDP-10 design based on the Jupiter architectural 
design which has a nominal performance that is kx a KLIO seems to 
be the best tradeoff between performance and time-to-market. 



